Pull request for new Overvote Rule: "Count When Single Continuing" #980
Conversation
…ballots with multiple continuing candidates
…apply to new overvote rule
…when next rank empty but not allowed
…when multiple continuing overvotes
…dit category for both temporary inactive and exhausted when overvote
|
@cpsolver thank you! This is a huge lift for you to make all this changes. And it is also a huge lift for our small team to review everything for potential inclusion. I know that time spent without review makes keeping updates in sync difficult. After a course review of the code changes, I know I need to think about the implications of a ballot going temporarily inactive at the time of an overvote with multiple continuing candidates and then being "revived" when there is only one remaining inactive candidate. Like for the logging, once a ballot is exhausted it no longer shows up in the logging. It assumes that a ballot doesn't "revive". We have a debugger app that parses the audit log to make a structured account for each ballot, for each round what bucket that ballot counts towards. I need to make sure the assumptions of that tool align with this update as well. |
2 participants
I've created a branch named "feature_issue_972_count_overvote_when_single_continuing". It implements the new Overvote Rule named "count when single continuing" which is described in issue 972.
Here's a graphic that quickly summarizes the need for this new feature:
https://votefair.org/count_overvote_when_single_continuing.png
The code in this branch correctly tabulates ballots using this new Overvote Rule. Specifically it counts a ballot for whichever overvoted candidate is still continuing after the other overvoted candidates have been eliminated. The ballot is counted as inactive while multiple overvoted candidates are continuing.
What refinements do you need?
Details:
My goal is to provide reference code for use by our election-system vendor when Portland or Oregon are ready to adopt this better Overvote Rule. I'm not trying to impose this better counting method on election districts that regard existing Overvote Rules as adequate.
The audit logging of CVR (cast vote record) transfers might need refinement. Partly that's because I don't see any tests regarding what's in the audit log. In particular, should an audit log message repeat in every round that a ballot is inactive while waiting for just one continuing overvoted candidate? Or should that audit message appear only once?
Currently the audit-logging code is strangely written to be inflexible, as if that Java class might be used in a different tabulation application. As a further limitation, this audit-logging code uses a null "target" value to indicate an exhausted ballot without allowing for the possibility of yet another reason the ballot might be inactive. I know how to improve that code's flexibility, but I don't want to waste time doing that if you already know you won't accept these refinements.
This branch also includes changes made by the Idea IDE in order to successfully run the "build" command ("./gradlew build"). These Gradle-related changes reveal part of why I was unable to run the unmodified RCTab software on a non-Ubuntu version of Linux in spite of following your installation instructions.
You will want to overwrite my version of the README file.